Intent

Retarget python-tesla-fleet-api to consume the published tesla-protocol PyPI package (Teslemetry/tesla-protocol, generated as tesla_protocol) as its source of Tesla protobuf definitions, replacing the vendored proto/ sources and generated tesla_fleet_api/tesla/vehicle/proto/ modules this repo previously mirrored. Goal: single source of truth - the API client already adopted the npm sibling package (@teslemetry/tesla-protocol), so this brings the Python library onto the same shared package. Verified before switching: tesla-protocol requires protobuf<7,>=6.32.0 and stamps gencode 6.31.1, both compatible with Home Assistant core's protobuf==6.32.0 pin (a hard blocking constraint since HA core depends on this library). All internal imports rewritten from tesla_fleet_api.tesla.vehicle.proto.X_pb2 to tesla_protocol.command.X_pb2 across the library, tests, and scripts/ble-harness; deleted proto/, tesla_fleet_api/tesla/vehicle/proto/, tools/regenerate_protos.sh, and createProto.sh since they are now redundant. No public API change - this is purely an internal source swap. During migration, discovered tesla-protocol 0.4.0 shipped generated .pyi stubs with a bug (bare, unresolvable cross-file imports caused by a protoc-pyi-generator vs protoletariat alias mismatch) that broke pyright strict mode on 14 lines in commands.py, with zero runtime impact (all tests passed). Rather than mask this with local pyright-ignore suppressions, fixed it at the source: opened and shipped Teslemetry/tesla-protocol#13 fixing the generator script and the checked-in stubs. That fix released as tesla-protocol 0.5.0, so the dependency floor here is bumped to >=0.5.0 and pyright is now clean with zero errors. Version bumped to 1.7.7 (separate commit per repo convention) since this is a released-quality dependency swap, not just an internal refactor. Full test suite (375 tests), ruff check, ruff format, and pyright strict all pass.

What Changed

• Replace vendored Tesla protobuf sources and generated bindings with the shared tesla-protocol>=0.5.0 PyPI package, updating library and test imports accordingly.
• Preserve existing tesla_fleet_api.tesla.vehicle.proto imports through compatibility aliases while removing the obsolete generation scripts and checked-in definitions.
• Bump the package version to 1.7.7 and refresh protobuf dependency metadata and documentation.

Risk Assessment

✅ Low: The follow-up restores the legacy protobuf import namespace with thin upstream re-export shims while preserving tesla-protocol as the single source of definitions; no material defects were found in the full diff.

Testing

Inspected the complete migration, ran targeted compatibility and command-path tests plus the full 376-test suite, demonstrated consumer serialization through tesla-protocol 0.5.0, and repeated the signed-command envelope check under Home Assistant’s exact protobuf 6.32.0 runtime; everything passed and no UI evidence was applicable because this is an internal Python-library dependency swap.

tesla_fleet_api=1.7.7
declared_dependency=tesla-protocol>=0.5.0
installed_tesla_protocol=0.5.0
protobuf_runtime=6.33.6
tesla_protocol_gencode_stamp=6.31.1
new_import=vcsec_pb2.VehicleStatus
legacy_import_same_class=True
serialized_vehicle_status=1001
round_trip_lock_state=VEHICLELOCKSTATE_LOCKED
result=consumer import, compatibility import, serialization, and parsing succeeded

protobuf_runtime=6.32.0
tesla_protocol=0.5.0
commands_imported=tesla_fleet_api.tesla.vehicle.commands.Commands
legacy_import_same_class=True
signed_transport_envelope_bytes=52021001
decoded_command=RKE_ACTION_LOCK
result=published protobuf package works at Home Assistant's exact protobuf pin

Pipeline

Updates from git push no-mistakes